[Immuta] Projectを設定してデータガバナンスを効かせつつ効率よくデータ分析を行えるようにする

大阪オフィスの玉井です。

Immutaは、データとユーザーの設定を行い、「誰に、どのデータを、どこまで見せるか？」をコントロールすることができます（データガバナンスを効かせることができる）。

Immuta自体については、下記をどうぞ。

便利なImmutaですが、登録するデータやユーザーの量が多くなってくると、データを探すだけでも一苦労になり、ガバナンスどころではなくなってきます。

Immutaには、Projectという機能があり、それを使うことで、データとユーザーを、共通の目的の元にまとめることができます。

Projectとは

（データ分析の）目的に基づいて、ユーザー（グループ）とデータを、論理的に1つにまとめたものです。

その目的に関するデータだけを設定して、そのデータを分析するメンバーだけをジョインさせることで、共同作業を効率よく実施することができます。

やってみながら理解していく

文字の説明だけど、結構わかりづらいので、いつものように、実際に触っていきます。

やること

今回は「顧客に関する分析を行うための設定」というテイで設定します。

作成するProjectには、顧客に関するデータと、そのデータを分析するメンバー2人を追加して、動作を検証します。

事前準備

今回のImmutaには、下記を設定済です。

• データ
  • Snowflakeのサンプルデータを使用
• ユーザー
  • shiro koshinaka
    • 「平成維震軍」というグループに所属
    • position: leader
  • kengo kimura
    • 「平成維震軍」というグループに所属
    • potision: sub-leader
• グループ
  • 平成維震軍
    • 新旧 : 旧ユニット
• サブスクリプションポリシー
  • 新旧という属性の値が「旧ユニット」であるグループは、Environment → devタグがついたデータソースを閲覧することができる

ちょっとややこしいですが、結果だけいうと、平成維震軍というグループに参加しているユーザーは、Devタグがついたデータソースを見ることができるようになっています（平成維震軍以外のメンバーは見れない）。つまり、今回用意したユーザーは、両方とも見ることができますね。

今回の2ユーザーで違うのは、ユーザー属性potisionの値です。このユーザー属性を使ってデータポリシーを設定すれば、同じデータに対して、この2人でそれぞれ違った見せ方を仕掛けることができます。

というわけで、それをしてみました。

今回使用する予定のCustomerというデータのカラムに対して、下記の設定をしています。

• potisionの値がleaderではないユーザーは、c_acctbalというカラムの値が100の位のレベルで丸められる
• potisionの値がleaderではないユーザーは、c_commentというカラムの値がハッシュ化される

leaderの値を持っていないユーザーは、2つのカラムで、実データを見ることができないようになっています。

ですので、shiro koshinakaは下記のようにデータが全て見えますが…

kengo kimuraは2つのカラムが丸められたりハッシュ化されてるようになっています。

この状態で、Projectを設定していきます。

Projectを作成する

Projectのページから、Projectを新規作成していきます。

設定値に関しては、下記の通りになりました。

Purposeについて

Projectの設定で「ん？」ってなるのが、Purposeです。これは、その名の通り、このProjectの目的を設定します。

いくつかサンプルも用意されていますが、今回は日本語のPurposeを新規作成してみました。

このPurposeを設定すると、このProjectに参加しようとするメンバーに対して「このPurposeに同意しますか？」という同意画面が出てくるようになります。（Purposeというより規約って感じ）。

この「同意」に何の意味があるのか？なのですが、同意したユーザーが何をしているのか、ログで追いかける事ができます。ですので、同意しておきながら、それに違反するような操作をしているユーザーを補足することができます。また、「このPurposeに同意したユーザーは〜」という感じで、Purposeの同意をポリシーの条件に組み込むこともできます。

ユーザーを入れる

Projectを作成したら、メンバーを追加します。先程説明した2ユーザーを入れます。

Project Equalizationを設定する

ここで、もう一つのImmuta独特の設定「Project Equalization」をONにします。

これは何かというと、Project内のデータに対するポリシーを均等にします。Immutaはユーザーやグループ毎に色々なポリシーを設定することができます。それ故、Projectに参加しているメンバー間でも、ポリシーの差異が出てきます。しかし、同じ目的に向かって共同作業しているのに、お互いで見れるデータが異なると、作業は上手く進みません（「このカラムの値がXXのレコードなんだけどさあ」「そのカラム、こっちではハッシュ化されててわかんないです…」「え？」みたいな）。そういう時に、この機能をONにして、Project内のメンバーは全員データの見え方を揃えるようにすると、より共同作業が捗るようになります。

デフォルトだと、均等化の設定はImmutaの推奨設定に（自動で）なります。今回でいえば下記のようになりました。

上記以外は省かれる（という表現が正しいか謎ですが）…つまり、ユーザー属性のpotisionがleaderかどうかというポリシーは関係なくなります。

このEqualized Entitlementsは、任意の内容に変更することもできますが、それによりデータが見られなくなるユーザーが発生する可能性もあり、調整が難しいので、原則、Immutaの推奨設定のままでよいと思います。

入れられたユーザー側で確認する

これまではProjectを作成してユーザーを入れるまでをやってきましたが、入れられたユーザー側はどのような感じになるのでしょうか。

shiro koshinakaでログインすると、「Projectに追加されたよ」という通知がきています。

通知を確認しようとすると（Projectに入ろうとすると）、先程設定したPurposeの同意画面が出てきます。同意しないと参加できないため、同意してProjectに参加します。

Projectに参加した後、データポリシーの動きを確認してみます。

まず、Projectに切り替えないで、Customerテーブルを参照します。shiro koshinakaは平成維震軍のleaderなので、カラムの値は全て見えます。

しかし、右上のProjectを「顧客分析」に切り替えて、再度Customerテーブルを参照すると、データポリシーが働いて、値が丸められたり、ハッシュ化されています。

これは、「顧客分析」というProjectで「Project Equalization」が有効化されて、kengo kimuraとポリシーが均等になっているためです。

このような形で、Project内のポリシーを均等にすることで、共同作業においてデータの見え方の差異をなくすことができます。

ポリシーが全く異なるユーザーを入れるとどうなるか

そもそも、この2ユーザーは、Devタグがついたデータを閲覧できる権限をもっていますが、それ自体が無いユーザーをProjectに入れるとどうなるのでしょうか。

Devタグがついたデータを、そもそも見ることができないユーザー（rei tamai）を「顧客分析」に追加します。すると、「Not in Compliance」というワーニングが出ました。

Devタグがついたデータを見られるのは、新旧という属性が「旧ユニット」という値のグループだけになります。そこに入っていないrei tamaiは、そもそもProject内のデータにアクセスする権限自体がないため、「このProjectに入ってもデータは見られないよ」という警告が出ているというわけです。

当然ながら、この状態だと、rei tamaiは該当データに対してクエリができません。

これまで、何気なく「ポリシー」としか書いてきませんでしたが、Project Equalizationというのは、あくまで「データポリシー」を均等化する、という認識でいたほうが良いです。サブスクリプションポリシー（データが見られるかどうか）は、そもそも満たしているのが前提となります。要するに、Projectに参加するメンバーは、そもそも前提として、Projectに登録されているデータにアクセスできる状態でないといけません。

ですので、「Project Equalization」をする場合、参加メンバーのサブスクリプションポリシーに注意を払う必要があります。

おわりに

概念の理解と使い方がかなり難しい機能だと感じました。ただし、設定をスパスパ変えることができるので、とりあえずまずはトライしてみながら覚えるしかないですね。